Blog

Życie składa się z drobiazgów, a niektóre drobiazgi ułatwiają życie. Dotyczy to nauki data science, a także w trakcie pracy "na serio". O jakich drobiazgach dziś opowiem?

• Dobre IDE. IDE (integrated development environment) jest łącznikiem pomiędzy interpreterem (w przypadku Py i R) a użytkownikiem. Zawiera dobry edytor, który ładnie podświetla składnię. Mój ulubiony PyCharm podpowiada mi jak poprawić czytelność kodu, kontroluje indentację w kodzie (wiadomo jakie to ma znaczenie w Py!) i pokazuje jakie obiekty mam w pamięci. Do R polecam RStudio, ale uczciwie mówię -- nie próbowałem innych.
• Cheat sheets. Ściągawki są dobre nie tylko na egzaminach ;) Takie ściągawki są fajne jako podręczny reference do kodu. Wiadomo, czasem zapomnimy, czasem potrzebujemy zrobić coś innego niż zwykle. Te z DataCamp są ok, ale w sieci jest wiele, każdy ma nieco inne potrzeby i gust, ale naprawdę można wybierać. Jeśli chcecie mieć jedną kartkę to do R używałem ofertowanej przez RStudio (tu). Ściagawki drukuję w kolorze na grubszym papierze (150 g). Można też wydrukować w formacie A3 i zawiesić jako plakat na ścianie.
• Notepad++. Oczywiście do naszego kodu najlepiej używać edytora w naszym ulubionym IDE. Jeśli trzeba podejrzeć duży plik .txt czy .csv - lepiej użyć jakiegoś dobrego edytora czystego tekstu (nie mylić z Wordem itp.). Notepad++ przydaje się kiedy musimy skorzystać z kodu napisanego w innym języku, np. dodajemy zapytania SQL albo przepisujemy kod Java do naszego ulubionego Py lub R. Oczywiscie N++ jest bezpłatny.

Jeśli znacie jakiś inny drobiazg, który ułatwia pracę (ale nie mówimy o ekpresie do kawy :) to proszę o maila, zamieszczę update cytując autora ciekawej propozycji.

Znane przysłowie mówi, że czym skorupka za młodu nasiąknie... Data science dopiero zaczynam, ale pracuję z danymi już kilkanaście lat. W praktyce poznałem jak ważne są dobre nawyki:

• Używanie właściwych narzędzi do właściwych celów. Przygotowanie środowiska pracy i koncepcji. Chyba nie wymaga komentarza - przygotuj się dobrze do analiz. Przemyśl metody, sprawdź wiele możliwości. Zastanów się z jakich danych chcesz skorzystać. Może ten projekt lepiej wykonam w Python niż R? Jak poradzę sobie z 60GB plikiem? Które dane nie są mi potrzebne? Jaki chcę output? Może lepiej gdy od razu pomyślę o wykresach - przyda mi się do raportu i prezentacji. Zrób raz, ale kompleksowo, to nie będziesz wracał do tematu piętnaście razy.
• Zdrowa równowaga pomiędzy: "zrobię wszystko sam od podstaw" a "wezmę gotowca". Nie zawsze wszystko trzeba robić samodzielnie. Np. odwracanie macierzy jest doskonale oprogramowane w R a do tego wbudowana funkcja zadziała znacznie szybciej niż kod R (łatwo sprawdzić dodając dwa wektory "wbudowanym" operatorem sumy i pętlą). Przesada w drugą stronę oznacza, że bierzemy tylko to co jest gotowe. Szybko, tanio i wygodnie :) Niestety, w takim przypadku nie wiemy czy działa i w jaki sposób działa. Najprostszy przykład to mediana ze zbioru: 0, 1, 3, 7. Najczęściej wynik będzie średnią z 1 i 3, ale nie zawsze. A 10 percentyl z takich 4 obserwacji? Okazuje się, że jest kilka możliwości, jeśli zbytnio zaufasz gotowcom - otrzymasz niezrozumiały (nieoczekiwany) wynik.
• Czystość kodu. To jest ważne, gdy nie jesteśmy jedynymi czytelnikami/autorami kodu. Nawet jeśli kod jest tylko dla nas, bałagan w kodzie spowoduje, że za rok nie będziemy rozumieli własnej twórczości. Dlatego zachowujmy kod czysty: (1) Nazwy zmiennych (a także klas, funkcji, plików...) odpowiadają temu co zawiera dana zmienna (czyli Page_adress, Sender_name zamiast x1, x2), (2) Używaj komentarzy! Rób to w trakcie pisania kodu, kiedy jeszcze doskonale wiesz po co tak napisałeś/aś, czemu służy dane zmienna. W komentarzach można też napisać o tym co jest jeszcze wymaga poprawy, uzupełnienia (np. "TODO: Dodaj sprawdzenie czy wektor jest niepusty."), (3) Nie komplikuj kodu. Potrójne list comprehension wygląda super mądrze, ale może w tym przypadku pętla (albo częściowo pętla) byłaby lepsza? Przydatne są konwencje kodowania a w dużych projektach wręcz wzorce projektowe.
• Dokumentowanie własnej pracy. Czyli coś więcej niż komentarze (które robi się głównie dla siebie lub własnego teamu). Jeśli jesteś programistą w dużej firmie to zapewne będziesz musiał robić dokumentację na bieżąco (i będziesz z tego rozliczany!). A jeśli nikt Ci nie każe tego robić? Moim zdaniem staraj się robić krótkie notatki z tego co robisz. Może będziesz w przyszłości robił podobny projekt? Albo napiszesz o tym artykuł naukowy czy wpis na blogu? Prędzej czy później przekażesz komuś nie tylko wyniki ale i "wnętrze projektu" - wtedy będzie trzeba conieco opisać, ale po czasie zapomnisz większość swoich genialnych pomysłów. Poszerzasz team? Zamiast tłumaczyć wszystko od zera, możesz dać opis tego co już jest i na tej podstawie wdrażać kolegę/koleżankę do pracy. Trzeba zrobić instrukcję obsługi? Super, mam już większość w swoich notatkach. Chcesz pochwalić się tym już jest zrobione albo dostać wynagrodzenie za ukończony etap projektu? Nie ma problemu, bo zapisywałeś sobie na bieżąco co się działo :) Docenisz to szczególnie kiedy będziesz "z drugiej strony". Zdarza się, że dostajemy dane z fajnym opisem albo przejmujemy projekt z dokumentacją. W bardziej pesymistycznej (realistycznej?) opcji możesz dostać: opis zbyt lakoniczny żeby cokolwiek zrozumieć albo dokumentację w zupełnie nie znanym Ci języku.

Oczywiście to są tylko zajawki, a każdy z tych punktów można rozwinąć, ale tak naprawdę najlepiej spróbować zastosować w praktyce (spróbuj, zobaczy że oszczędzi to trochę czasu i nerwów).
Wreszcie na koniec dwie krótkie refleksje. Same obliczenia to tylko 10% pracy. Większość czasu zajmie Ci zrozumienie danych, wstępna obróbka (usunięcie braków danych, filtracja błędów technicznych - w miejscu gdzie oczekujemy liczby znajduje się tekst albo w bazie brakuje pewnych informacji, weryfikacja logiczna danych - obejrzyj dane, popatrz czy nie ma tam np. ujemnych zarobków albo czy średnia liczba dzieci w gospodarstwie domowym nie odbiega za bardzo od tego co wiemy z ogólnodostępnych danych demograficznych - jeśli tak to dlaczego?, ograniczenie zbioru). W przypadku data science dochodzą jeszcze techniczne wyzwania związane z bardzo dużymi zbiorami danych. Być może będzie trzeba zainstalować jakiś serwer bazodanowy albo zastosować jakiś szybszy algorytm? No, a na koniec trzeba to jeszcze opisać i zrobić prezentację.Teoria też jest ważna. Wszyscy mówią teraz, że studia mają uczyć praktyki, oczekujemy praktycznych rad czy wręcz gotowców. Uwierzcie mi, jestem praktykiem. Ale z czystego lenistwa warto zapoznać się z teorią - przykłady już wkrótce na blogu.

Data science zdominowały R i Python. Który wybrać?

Początkowo nie ma to wielkiego znaczenia (musimy poznać metody, a te w zasadzie nie zależą od implementacji). Problem ten pojawia się gdy chcemy nabrać praktyki, wykonać jakieś ćwiczenia na danych. Poniżej fajne strony w tej kwestii, odniosę się do nich bliżej wkrótce.
R czy Python [datacamp.com]
R czy Python [webhose.io]

W krótkich żołnierskich słowach -- główna różnica pomiędzy R a Py to punkt wyjścia twórców.

• R jest bardziej pakietem statystycznym (najbardziej przypomina Matlab, ale jego przeznaczeniem jest wykonywanie obliczeń - jak w Mathematica, Statistica, Stata, SPSS czy Gretl). Dlatego R domyślnie wyświetla wyniki na ekranie, podstawowym rodzajem danych jest wektor, domyślnie posiada też pakiet DataFrame (dla niewtajemniczonych: daleki odpowienidk arkusza w Excelu).
• Python jest pomyślany jako język programowania, wobec czego niekoniecznie musi być używany do obliczeń (można w nim napisać np. grę komputerową). Oczywiście w ramach pakietu R możemy używać skryptów i funkcji, napisanych w języku R.
• Dzięki dodatkowym bibliotekom, różnice pomiędzy R a Python zmniejszają się. Np. używając biblioteki pandas możemy obrabiać dane podobnie jak w R. Istnieje sporo bliżniaczych (R / Py) bibliotek, np. Keras, NLTK, Selenium, itp.
• Pomiędzy tymi pakietami jest wiele podobieństw. Oba są darmowe (w przeciwieństwie do Matlab), oba mają bogaty zasób bibliotek do data-science. Skrypty w R są interpretowane, podobnie jak programy w Py.

Jeśli bliższe Ci jest programowanie niż algebra czy statystyka - zapewnie będziesz zadowolony z Python (ale z drugiej strony w data-science oba komponenty są nieuniknione: programowanie oraz praca na wzorach i danych).
Jeśli używałeś Matlaba - łatwiej zaczniesz z R (zob. słownik R-Matlab).
Jeśli naturalnym sposobem zapisu jest wektor/macierz i większość operacji będzie wykonywana "wektorowo" - polubisz R.
Jeśli lubisz oglądać dane i na bieżąco wyniki na ekranie - raczej R.
Jeśli Twój program będzie działał na serwerze albo na przenośmym środowisku na USB - znacznie łatwiej to osiągniesz używając Python.

Moim naturalnym punktem wyjścia jest oczywiście praca na danych. Dzięki doświadczeniu w Matlab, kiedy potrzebowałem przesiąść się na R - zajęło mi to kilka dni metodą prób i błędów. Rozpoczęscie obliczeń w Python trwało trochę dłużej, mimo że znałem podstawy programowania. Mimo wszystko -- sam wolę Py i nowe projekty staram się robić w tym języku. Nie oznacza to, że tego co robię nie można zrobić w R! Dla obecnych zastosowań nie wielkich różnic, a osobście podoba mi się zwięzłość Py. Wydaje mi się, że środowisko użytkowników Py zapewnia trochę więcej wsparcia np. na stackoverflow.com.

Oczywiście w pracy zespołowej, nie zawsze mamy wybór. Przykładowo -- trafiam do zespołu, który ma rozpoczęty projekt albo mój szef ma silną preferencję któregoś z podejść. Poza tym polityka bezpieczeństwa firmy może nie pozwalać na instalację R czy Python. Na początek zacznij od tego podejścia, które wolisz, a prędzej czy później dojdziesz do tego, że warto poznać choćby podstawy innych podejść (być może nie tylko z grona R/Py).